Subject: Re: An architectural framework? Choon Lee's proposals on Loop Prevention SIGlet Other proposals on other SIGlets

From: Choon Lee <[email-masked]>
Date: Wed, 18 Aug 1993 16:37:33 -0700

Marcia,

>> 
>> The problem I've been having with discussions on several of the siglets
>> is that connections between DLSW nodes for network control purposes (e.g.
>> CANUREACH, ICANREACH) are assumed to be the SAME connections on which
>> data is routed.
>> 
>> Here's a simple architectural framework that has helped me sort out some
>> of this complexity.  I see the DLSW as having 3 functional components:
>> 
>> (1) An access piece.  How the DLSW interacts with specific datalinks and
>>     non-routable LAN protocols.  The semantics of which frames should be
>>     handled as address resolution protocols, flow control protocols,
>>     circuit establishment/takedown triggers, or just plain data to send.
>>     How the DLSW keeps track of addressable network-layer entities on
>>     attached LANs.  How multiple DLSWs on the same LAN coordinate which
>>     one will perform specific functions on behalf of a network-layer
>>     entity.  Some people call this ES-IS.
>> 
If we have a routing update protocol in DLSw just like other routing protocols,
then we don't have to worry about loops? :-)

>> (2) A network control piece.  Establishment of transport connections
>>     between appropriate DLSWs to be used for exchange of control
>>     information.  Current control information is limited to things like
>>     CANUREACH, ICANREACH (I consider this an address resolution protocol
>>     not too dissimilar to APPN's).  Additional control functions could
>>     potentially be implemented, depending on the amount of dynamics
>>     customers require.  Some people call this IS-IS.
>> 
>> (3) A data transport piece.  Currently, data flows on TCP/IP transport
>>     connections, the same DLSW TCs that are used for network control,
>>     but this would not necessarily have to be the case in the future.
>>     One of the siglets was having some discussions about bringing up and
>>     taking down TCs dyamically as needed.
>> 
>> Using this framework it seems that loop prevention (a la 802 spanning
>> tree) doesn't necessarily contradict having a mesh of control connections
>> between the switches.  Having a mesh is an entirely separate issue
>> (probably undesirable from a scalability standpoint, however).
>> 
Can you please elaborate on that? The loop prevention SIGlet is having doubts
about the ability of an 802.1d spanning tree to solve the loop problem for
DLSw.

>> I mentioned this over lunch at SHARE with Richard Livingston, Anson Chen
>> and Al Schwartz from Cisco, and they seemed to think this paradigm made
>> sense and makes this problem easier to think about.  What do you think?
>> Is this framework helpful?
>> 
>> Marcia Peters - Networking Systems Architecture - IBM
>> 

Regards,
Choon Lee
3Com Corp